Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

test: enable marking of failing coverage tests #25671

Closed
wants to merge 6 commits into from

Conversation

mhdawson
Copy link
Member

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines

Enable marking of coverage tests so that we can
allow some tests to fail without blocking the generation
of coverage data. This will later allow us to
fail the coverage job if other kinds of errors occur and
to capture which tests we believe are not running properly
with coverage enabled.

This is step 1 of the following

  • allow us to run coverage and have failing tests not block generation of results
  • add support for a coverage level check (ex 90%) that will cause a failure @bcoe is working on that
  • add job to main PR regression test that will run coverage to make sure new failing tests are
    not introduced
  • Update makefile so that we don't use '-' for the coverage target. At this point we will fail is
    some other problem occurs but not if one of the known tests that affects coverage fails.

Note that this re-uses the '--type' option that we used for fips testing so that we can have entries
in the status files. The downside is that we would not be able to run coverage on FIPs as they
would conflict trying to use different types. I could add another option '--test-type' but I was
not sure if the added code/complexity is what people would want so I started with this approach.

Enable marking of coverage tests so that we can
allow some tests to fail without blocking the generation
of coverage data. This will later allow us to
fail the coverage job if other kinds of errors occur and
to capture which tests we believe are not running properly
with coverage enabled.
Allow FAIL and CRASH to avoid yellow, otherwise
if we added to regular CI run we'd have perma-yellow
Allow new tests to fail until we get a ci job added
to the main regression job so that comits don't break
coverage that have to be fixed later on.
@nodejs-github-bot nodejs-github-bot added build Issues and PRs related to build files or the CI. test Issues and PRs related to the tests. tools Issues and PRs related to the tools directory. labels Jan 23, 2019
@mhdawson mhdawson requested review from bcoe and refack and removed request for bcoe January 23, 2019 22:16
@mhdawson
Copy link
Member Author

FYI , job in the CI that I've been using for testing and that we'd want to add to the main regression PR.

https://ci.nodejs.org/job/node-test-commit-coverage/

One thing is which machines to run it on, currently coverage requires patch which does not seem to be installed on all of our machines. Maybe just run it on the machines we using for linting? @refack what do you think?

Copy link
Contributor

@bcoe bcoe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mainly just had some questions, thank you for doing this.

[$system==aix]

[$type==coverage]
test_function/test: PASS,FAIL,CRASH
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this approach to isolating flaky tests a lot 👍 first saw it in the blink codebase.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You might consider putting this in https://github.com/nodejs/node/blob/master/test/root.status
My intuition is that file fit better to represent this is a cross-cutting concern.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You learn something new every day. I was not aware of that option. I like having the list in one place so will move there.

Makefile Outdated
@@ -226,7 +226,8 @@ coverage-test: coverage-build
$(RM) out/$(BUILDTYPE)/obj.target/node_lib/gen/*.gcda
$(RM) out/$(BUILDTYPE)/obj.target/node_lib/src/*.gcda
$(RM) out/$(BUILDTYPE)/obj.target/node_lib/src/tracing/*.gcda
-NODE_V8_COVERAGE=out/$(BUILDTYPE)/.coverage $(MAKE) $(COVTESTS)
-NODE_V8_COVERAGE=out/$(BUILDTYPE)/.coverage FLAKY_TESTS="dontcare" \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this just to prevent FLAKY_TESTS from being overridden by an environment variable, so that js-native-api.status is used?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

by default it is "run" which means it will fail if the tests crashes, this means if the test is marked flaky it will still not be marked as failed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Can you double check that... Since you are not marking the tests FLAKY? Maybe we should keep this consistent with other CI target and just use dontcare as an override-able default?

  2. Can we now remove the - prefix?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was on the fence on overriding the dontcare. I think I'll remove for now.

In terms of removing - I don't want to do that until we have a job running (similar to the linter) in the main regression job. I want to avoid the case were a test goes in that breaks coverage and then somebody else (people keeing coverage going) are expected to fix it. As soon as we get the coverage check as part of the regression PR then we will remove it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the dontcare. To clarify I added that when I marked them as FLAKY but that did not actually work because the builds would then always be yellow which I don't think we wanted. Given that we'd probably we probably have to use FAIL or CRASH I removed the setting of dontcare.

@@ -277,7 +278,7 @@ coverage-run-js:
$(RM) -r out/$(BUILDTYPE)/.coverage
$(MAKE) coverage-build-js
-NODE_V8_COVERAGE=out/$(BUILDTYPE)/.coverage CI_SKIP_TESTS=$(COV_SKIP_TESTS) \
$(MAKE) jstest
TEST_CI_ARGS="$(TEST_CI_ARGS) --type=coverage" $(MAKE) jstest
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would probably make sense to also specify:

FLAKY_TESTS="dontcare"

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

k will add.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

based on @refack's comment I'll leave out setting dontcare completely for now.

Copy link
Contributor

@refack refack left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left some questions

Makefile Outdated
@@ -226,7 +226,8 @@ coverage-test: coverage-build
$(RM) out/$(BUILDTYPE)/obj.target/node_lib/gen/*.gcda
$(RM) out/$(BUILDTYPE)/obj.target/node_lib/src/*.gcda
$(RM) out/$(BUILDTYPE)/obj.target/node_lib/src/tracing/*.gcda
-NODE_V8_COVERAGE=out/$(BUILDTYPE)/.coverage $(MAKE) $(COVTESTS)
-NODE_V8_COVERAGE=out/$(BUILDTYPE)/.coverage FLAKY_TESTS="dontcare" \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Can you double check that... Since you are not marking the tests FLAKY? Maybe we should keep this consistent with other CI target and just use dontcare as an override-able default?

  2. Can we now remove the - prefix?

[$system==aix]

[$type==coverage]
test_function/test: PASS,FAIL,CRASH
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You might consider putting this in https://github.com/nodejs/node/blob/master/test/root.status
My intuition is that file fit better to represent this is a cross-cutting concern.

@refack refack added the coverage Issues and PRs related to native coverage support. label Jan 24, 2019
@mhdawson
Copy link
Member Author

@mhdawson
Copy link
Member Author

Opened issue for un-related failure on Windows: #25702

@mhdawson
Copy link
Member Author

Created issue for unrelated issue on ARM - #25704

@mhdawson
Copy link
Member Author

@mhdawson
Copy link
Member Author

mhdawson commented Jan 25, 2019

Resume again to try and get passed the arm issue: https://ci.nodejs.org/job/node-test-pull-request/20336/

@mhdawson
Copy link
Member Author

@addaleax
Copy link
Member

I don’t think the ARM issue is resolvable through Resume CIs, sadly 😕

Rebuild CI: https://ci.nodejs.org/job/node-test-pull-request/20388/

@addaleax addaleax added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Jan 28, 2019
@danbev
Copy link
Contributor

danbev commented Jan 29, 2019

Landed in c06653e.

@danbev danbev closed this Jan 29, 2019
danbev pushed a commit that referenced this pull request Jan 29, 2019
Enable marking of coverage tests so that we can
allow some tests to fail without blocking the generation
of coverage data. This will later allow us to
fail the coverage job if other kinds of errors occur and
to capture which tests we believe are not running properly
with coverage enabled.

PR-URL: #25671
Reviewed-By: Ben Coe <bencoe@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Refael Ackermann <refack@gmail.com>
targos pushed a commit that referenced this pull request Jan 29, 2019
Enable marking of coverage tests so that we can
allow some tests to fail without blocking the generation
of coverage data. This will later allow us to
fail the coverage job if other kinds of errors occur and
to capture which tests we believe are not running properly
with coverage enabled.

PR-URL: #25671
Reviewed-By: Ben Coe <bencoe@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Refael Ackermann <refack@gmail.com>
@targos targos mentioned this pull request Jan 29, 2019
@mhdawson
Copy link
Member Author

@addaleax thanks. So that I know for the future is there a way to tell when an error won't work through resume CI or does that apply for ARM in general?

@addaleax
Copy link
Member

@mhdawson I have no idea – I think the reason is that resume builds might not do an additional rebase against master, where the test had been fixed in the meantime…?

@mhdawson mhdawson deleted the coverage-tests branch September 30, 2019 13:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
author ready PRs that have at least one approval, no pending requests for changes, and a CI started. build Issues and PRs related to build files or the CI. coverage Issues and PRs related to native coverage support. test Issues and PRs related to the tests. tools Issues and PRs related to the tools directory.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants